Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds a new pattern for defining R code chunks within a LaTeX environment, replacing the <<>>= ... @ syntax.
The pattern is associated with files with an .RLatex extension. Ideally, I would like this syntax to be just another option for .Rnw files, but for now, I think this approach is less likely to create conflicts with existing code.
Why did I do this? My development environment is emacs/ESS, and when writing ordinary LaTeX documents, I use the preview-latex emacs package to preview LaTeX math inline. However, preview-latex chokes on R code chunks, and I have not found a way to tell it to skip everything between <<>>= and @. But I can tell preview-latex to skip an environment. So preview-latex thinks the code chunk is just an environment to skip, and knitr knows that the Rcode environment contains code to be knitted. Everyone is happy.
I created a gist that goes into more detail, with examples (including some additions to the LaTeX preamble). The gist also contains a new polymode, so ESS can recognize the contents of the Rcode environment as code, and execute syntax highlighting, indentation, etc., appropriately. That's not part of knitr, but I mention it here for those who are interested.
Of course, I could just define the pattern in a hook to run whenever knitr loads. But that would make my documents non-portable. So I am hoping this contribution is worthy of addition to the package, and that others can benefit.